IRIX Installation Tools & Overlays 2001 May

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Installation Tools & Overlays 2001 May / SGI IRIX Installation Tools & Overlays 2001 May - Disc 3.iso / relnotes / license_eoe / ch8.z / ch8

Wrap

Text File | 2001-04-16 | 32KB | 991 lines

- 1 - 8. _G_l_o_b_e_t_r_o_t_t_e_r__F_L_E_X_l_m__R_e_l_e_a_s_e__N_o_t_e_s Flexible License Manager Version 7.2e RELEASE NOTES MARCH 27, 2001 These release notes describe the changes from FLEXlm v7.0 and recommend migration paths for implementing these changes. If you are new to FLEXlm, please skip ahead to the section "For companies new to FLEXlm". Version 7.2 is functionally equivalent to v7.1. There will be no further patches to v7.1, since v7.1 is the patched version of v7.1 Summary of v7.1 Enhancements from v7.0 ______________________________________ Counterfeit Resistant Option (CRO) __________________________________ V7.1 contains an separately priced option called CRO, which can be used to reduce the possibility of counterfeit licenses. Counterfeiting is the most serious threat to FLEXlm security, and CRO utilizes industry-standard cryptography recommended by the US government for its own secrets to reduce the possibility of counterfeiting. CRO utilizes Certicom's Public-Key system based upon Elliptical Curve Cryptography, which is considered secure, fast and efficient (see www.certicom.com). This option is enabled in the vendor keys you receive from Globetrotter if you purchase FLEXlm with the CRO option and is enabled by default in the evaluation kit. If you attempt to use CRO without these special vendor keys, you will receive the error: "FLEXlm function not available." Other enhancements - 2 - __________________ Better client security. The only other change is a security enhancement in the client that prevents a particular type of attempted theft. It will require your applications to be linked with v7.1, but does *not* require the CRO option to be enabled. Enhanced DLL security. Use of the FLEXlm DLL on windows remains strongly discouraged. However, for companies that choose to use the DLL, the security provided by lm_new.obj is now available with the DLL, and is therefore better at preventing counterfeiting than previous version. Note that this requires using the Flexible API (lc_xxx()). lc_cryptstr now reports warnings with 8-bit characters in FEATURE lines. Only 7-bit ascii is supported. To turn off these warnings, OR in the LM_CRYPT_IGNORE_FEATNAME_ERRS to the flag option. CRO Migration Overview ______________________ If You Do Not Want CRO ______________________ If you're upgrading to v7.1, and do not want CRO, in machind/lm_code.h, set LM_STRENGTH to LM_STRENGTH_LICENSE_KEY. This is the only change you need make. Migrating to v7.1 with CRO __________________________ The recommended implementation of CRO uses public-key encryption technology and utilizes an additional attribute (SIGN=) on each FEATURE line in the license file, a v7.1 CRO vendor daemon, and a v7.1 CRO application. Planning your strategy for deploying applications with CRO can minimize the cost of supporting your customers during the migration. ISVs who have already shipped FLEXlm-based products and who want to implement CRO must make the following decisions, both involving trade-offs: 1) How strong to make the CRO security? The tradeoff is security vs the length of the new SIGN= attribute, which can be 58-120 characters long. - 3 - 2) When to enable CRO in a release of an application? The tradeoff is license security vs. end-user and software vendor convenience. CRO Questions and Answers _________________________ What Exactly is CRO? CRO utilizes industry recognized public-key encryption. There are four different encryption key lengths offered. The longer the encryption Key, the higher degree of security. How Secure Is This? To put this in perspective, the supplier of the elliptical curve cryptography (ECC) employed by the Counterfeit Resistent Option has an ongoing challenge with a maximum $100,000 reward to crack their cryptography. A researcher required 195 volunteers, 40 days of calculation, 16000 MIPS years of computation, and 740 computers located in 22 countries to solve a 97-bit key, which is weaker than any of the CRO options. Why Wouldn't I Want CRO? There may be those who feel no need to upgrade their security and see the length of the SIGN= attribute as inconvenient. The lengths of the SIZE= attribute in the license are: 58 chars (113 bits ECC) 84 chars (163 bits ECC) 120 chars (239 bits ECC) Can I get the new FLEXlm v7.1 without CRO? Yes, CRO is an optional addition to the FLEXlm product. What do I have to do to take advantage of CRO? There are three components that comprise CRO 1. v7.1 license file with the additional field: SIGN="1234 5678 90AB CDEF 1234 5678 90AB CDEF 1234 5678 90AB CDEF" 2. v7.1 CRO-enabled vendor daemon 3. v7.1 CRO-enabled application requires a v7.1 CRO vendor daemon and v7.1 license file with SIGN= in order to run. What problems am I likely to encounter? - 4 - If a v7.1 CRO-enabled application attempts authentication from a pre-v7.1 vendor daemon and/or license file, an error message will be displayed and the application will not run. The error message will inform you that either license file and/or vendor daemon is not v7.1 CRO compliant. It's important to remember that the v7.1 CRO application itself is the "trigger" that requires both a v7.1 license file and vendor daemon in order to run. What happens if a v7.1 vendor daemon encounters a pre-v7.1 License (without "SIGN=")? The system will perform exactly the way it does now -- it will support pre-v7.1 applications. What happens if a pre-v7.1 application encounters a license file with SIGN= and a v7.1 vendor daemon?. The system will perform exactly the way it does now. The following chart only applies to applications implementing CRO: Application Vendor Daemon License File Result ___________ _____________ _____________ ______ Pre-v7.1 Pre-v7.1 Pre-v7.1 no change Pre-v7.1 Pre-v7.1 SIGN= no change Pre-v7.1 CRO Pre-v7.1 no change Pre-v7.1 CRO SIGN= no change CRO Pre-v7.1 SIGN= FAIL CRO CRO Pre-v7.1 FAIL CRO CRO SIGN= CRO The goal is simply to have v7.1 license files with SIGN= attributes and v7.1 vendor daemons in place BEFORE distribution of CRO applications. For many companies, it will be advantageous to delay enabling CRO in applications, to reduce support calls and customer inconvenience, with the cost of a delay in the actual implementation of the extra security provided by CRO. The most effective method of accomplishing this may depend on how your company typically updates it's customer licenses. What is public-key technology? Public-key is based on mathematics, not "hiding" (obfuscation), which is what the "Standard" FLEXlm signature (without CRO) uses. There are 2 tasks to be accomplished for the SIGN= attribute: - 5 - 1) Generate digital signature (license-key) -- lmcrypt 2) Authenticate digital signature -- application and vendor daemon Without public-key, there's 1 "key", which is the same key in lmcrypt that's hidden in the applications and vendor daemon. With public-key, there's 2 different keys: private/public. The private key, used only in the license generators (lmcrypt), generates the SIGN= attribute. The public key, used by applications and vendor daemon authenticates the SIGN= attribute. It is difficult (but not impossible) to derive private from public-key; the longer the signature the harder it is to derive. In practice, the signatures used by FLEXlm would require large resources, considerable mathematical skill, and time. How To Migrate To CRO _____________________ First you have to make the two decisions: 1) What length SIGN= attribute do you want? 2) For each application, you need to decide when to enable CRO. What length SIGN= attribute do you want? ________________________________________ 58 char (113-bit) 84 char (163-bit) 120 char (239-bit) This decision determines what strength of protection you want against counterfeiting. Here are samples of FEATURE lines with each length: LM_STRENGTH_113BIT (58-chars): FEATURE f1 xyzd 1.0 permanent uncounted 1234567890AB SIGN="1234 5678 90AB CDEF 1234 5678 90AB CDEF 1234 5678 90AB CDEF" HOSTID=ABCDEF1234 LM_STRENGTH_163BIT (84-chars): FEATURE f1 xyzd 1.0 permanent uncounted 1234567890AB SIGN="1234 5678 90AB CDEF 1234 5678 90AB CDEF 1234 5678 90AB CDEF 1234 5678 90AB CDEF 1234 5678 90AB CDEF 1234" HOSTID=ABCDEF1234 LM_STRENGTH_239BIT (120-chars): FEATURE f1 xyzd 1.0 permanent uncounted 1234567890AB SIGN="1234 5678 90AB CDEF 1234 5678 90AB CDEF 1234 5678 90AB CDEF 1234 5678 90AB CDEF 1234 5678 90AB CDEF 1234 5678 90AB CDEF 1234 5678 90AB CDEF 1234 5678" HOSTID=ABCDEF1234 Once you've decided on a length, edit machind/lm_code.h and set - 6 - LM_STRENGTH to the proper value, make sure ENCRYPTION_SEEDs 3 and 4 are set to 32-bit numbers that you make up, and build the kit using make (unix) or nmake (windows). For each application, you need to decide when to enable CRO ___________________________________________________________ Support problems occur with CRO-enabled applications where 1) the client does not yet have a SIGN= license, or 2) the client is not using a v7.1 CRO vendor daemon. These problems can be delayed or sometimes avoided completely by delaying enabling CRO in applications. Delaying also delays protection, so if your company requires the highest security available immediately, then do not delay enabling CRO. The default behavior will be that CRO *is enabled*. To disable CRO in a particular application: Simple/Trivial API: OR (|) LM_USE_LICENSE_KEY into the policy, for example: CHECKOUT(LM_RESTRICTIVE|LM_USE_LICENSE_KEY,...) FLEXible API: Call lc_set_attr(job, LM_A_KEY_LEVEL, (LM_A_VAL_TYPE)0); Here are some guidelines for delaying CRO in applications: 1) All applications which ship for the first time after v7.1 should have CRO enabled from the start. This gives the maximum protection immediately and no migration problems will occur, since the product is new. 2) As noted above, make sure you ship SIGN= and license-key in all licenses, and v7.1 CRO vendor daemon ASAP. That way, when you do enable CRO in a particular application, the customer is less likely to encounter a problem. 3) If licenses for a particular application all expire over the next year, then you can safely turn on CRO after a year, since users will require new licenses to run anyway. 4) If the version in the checkout call will change, then it's safe to enable CRO, since the users will require new licenses - 7 - with the new version in order to run anyway. 5) If licenses don't expire, and versions don't change, then the longer you delay, the smoother the transition will tend to go, since more customers over time will have the requisite SIGN= licenses and v7.1 CRO vendor daemons. Of course, the longer you delay, the longer your applications to subject to possible counterfeit licenses. Remember ________ 1) Make sure all licenses ship with both license-keys and SIGN= attributes. 2) Ship v7.1 CRO-enabled vendor daemon and v7.1 lmgrd immediately and make this easily available to all customers. 3) Delaying CRO in applications will ease transition, but offers reduced security during this transition period. Enhanced Windows DLL Security ______________________________ The security available with lm_new.obj is now available with the Windows DLL and the FLEXible API, provided the application can link in a single .obj file. The only change from previous versions is that you must now add "lc_new_job_arg2" as the 2nd argument to lc_new_job, as in machind/lmflex.c: if (lc_new_job(0, lc_new_job_arg2, &code, &lm_job)) { lc_perror(lm_job, "lc_new_job failed"); exit(lc_get_errno(lm_job)); } This is safe for DLL and non-DLL code. Then, you must link lm_new.obj into your application. If you cannot link an object file into your application, then you cannot take advantage of this security feature, and you must call lc_init(), as in the past. For Companies New To FLEXlm ___________________________ FLEXlm offers a Counterfeit Resistant Option (CRO), which is a - 8 - separeately priced add-on. Without CRO, FLEXlm utilizes the standard FLEXlm signature, which uses a proprietary, non-public-key digital signature method. CRO offers a standard public-key system which is recognized by the security community, and recommended for US government work (with US government export approval). The system comes from Certicom (www.certicom.com) and uses Elliptical Curve Cryptography. What is the difference between CRO and standard FLEXlm signature? With standard FLEXlm signature, it is easier and more likely that a license file might some day be counterfeited. With CRO, the possibility becomes remote. To date, the current version of the standard FLEXlm signature has not been compromised. First you must decide whether you want to use CRO. The evaluation vendor-keys include CRO, so you can test CRO with the eval kit, although by default the evaluation kit does not use CRO. You have to set LM_STRENGTH appropriately in machind/lm_code.h for CRO to be tested. If you decide that you want to use CRO, then you have to decide what *length* signature (SIGN=) attribute you want, by setting the LM_STRENGTH value in machind/lm_code.h: LM_STRENGTH_DEFAULT 12 characters (Non-public-key) LM_STRENGTH_113BIT 58 characters LM_STRENGTH_163BIT 84 characters LM_STRENGTH_239BIT 120 characters All of the values from 113-239 are currently considered very secure. The highest compromised value from Certicom to date is 97-bit, and this required 195 volunteers, 40 days of calculation, 16,000 MIPS years of computation, and 740 computers located in 22 countries. The 239-bit value is considered strong enough that it will be infeasible to crack with anyone's resources for many years. If you set LM_STRENGTH to 113-239 bit, then you must rebuild the FLEXlm kit, using make in the platform directory (e.g., sun4_u5), or nmake on windows. If security is important to you, but a 58-character length for SIGN= attribute is unacceptable, then there is a compromise available, called Phase-2 security, which is also part of the CRO option, although this is not normally recommended since it does not use public-key encryption. Instructions for Phase-2 are available upon request to support@globes.com. - 9 - Platform Specific Notes: ________________________ WINDOWS _______ it64_n -- Windows Whistler for Itanium 64-bit ______ Built with: __________ - Microsoft Platform SDK PreRelease 64-bit (2416.2) - Microsoft C/C++ compiler version 13.00.9076.3 for IA-64 - Microsoft Incremental Linker version 7.00.9076.3 - Microsoft Program Maintenance Utility version 7.00.8827 - Microsoft Whistler Advanced Server for Itanium Build 2410 In This Build: _____________ - All GUI application tools are 32-bit. - All command-line application tools are 64-bit native. - All necessary libraries and header files are included to build a FLEXlm enabled application. - Support for CRO. See standard FLEXlm v7.2d RELEASE_NOTES in ./machind for further information about CRO support. Known Issues: ____________ - LCM and FLEXlock support not available. - LMTOOLS.EXE utility is not fully functional. This will be fixed in future released of this port. - Parallel Dongle (FLEXid) support not available. - CPU Serial number support (Pentium III) not available on Itanium Chip. - The following situation can occur while building a vendor daemon in it64_n: if exist lm_new.c del lm_new.c lmrand2.exe demo.exe -o lm_new.c Verify failed, 0xc6f8 != 0x30f8NMAKE : fatal error U1077: 'lmrand2.exe' : return code '0xffffffff' Stop. The workaround for this error is to run the NMAKE again. This error may occur many times before a successful build. This problem will be resolved in the final release. - 10 - UNIX ____ alpha_r6 -- Alpha Redhat 6 ________ uname -a: Linux chumley.globes.com 2.2.14-6.0 #1 Tue Mar 28 16:56:56 EST 2000 alpha unknow cc: /usr/bin/cc alpha_u3 -- Compaq Tru64 Dec Unix Alpha OSF1 OS3+ ________ Compatible with OS3 and higher Note that lmstrip should be avoided on this OS, due to outstanding bugs. However, lmstrip doesn't provide any additional security on this OS, so it shouldn't be needed. uname -a: OSF1 zippy.globes.com V3.2 17 alpha cc: /usr/ccs/bin/cc -std hp700_u10 -- HPUX 10.x through 11.x 32-bit ________ uname -a: HP-UX oglobes B.10.20 A 9000/715 2005771344 cc: /bin/cc -Aa -D_HIUX_SOURCE -D_HPUX_SOURCE +DA1.0 +DS1.0 Hostid note: we no longer recommend using ethernet address as a hostid. It may fail on some HPUX 11.x systems. hp64_u11 -- 64-bit HP PA-RISC _____________________________ uname -a: HP-UX hpc180 B.11.00 A 9000/780 2013810305 two-user cc: /bin/cc -D_HIUX_SOURCE -D_HPUX_SOURCE +DA2.0W +DS2.0W i86_b2 ______ uname -a: BSD/OS bsdi.globes.com 2.1 BSDI BSD/OS 2.1 Kernel #1: Mon Jun 10 15:58:19 MDT 1996 polk@demiurge.BSDI.COM:/usr/src/sys/compile/GENERIC i386 cc: /usr/bin/cc i86_f3 ______ This is the freebsd platform. We no longer support i86_f2, which is incompatible with i86_f3. i86_f3 however, is completely compatible with i86_f4 (freebsd 4.x) - 11 - uname -a: FreeBSD homegrown.globes.com 3.4-RELEASE FreeBSD 3.4-RELEASE #0: Mon Dec 20 06:54:39 GMT 1999 jkh@time.cdrom.com:/usr/src/sys/compile/GENERIC i386 cc: /usr/bin/cc i86_l1, i86_g2, i86_r6 Linux ______________________ i86_l1: Caldera linux, Redhat 4 i86_g2: Linux with GLibc, Redhat 5 i86_r6: Redhat 6 i86_g2 binaries will run fine on Redhat 6, but when mixing objects and libraries between redhat 5 and 6, when linked and run, will not behave correctly. i86_l1 binaries will *appear* to run on Redhat 5, but will fail with wierd errors. i86_u7 -- Unixware 7 ______ uname -a: UnixWare unixware7 5 7 i386 x86at SCO UNIX_SVR5 cc: /usr/ccs/bin/cc i86_n3 -- 32-bit windows 95, 98, NT, 2000, ME ______ cl: Microsoft Visual C++ v5 and higher rs6000_u3 AIX 3.x through 4.x, Power PC and RS6000, 32-bit _________ uname -a: AIX rs6000 1 3 000276513100 cc: /bin/cc -D_BSD -D_BSD_INCLUDES link flags: -lbsd rs64_u4 64-bit AIX _______ uname -a: AIX rs64 3 4 000687724C00 cc: /usr/ibmcxx/bin/cc -DRS64 -DRS6000 -D_BSD -D_BSD_INCLUDES -q64 link flags: -lbsd -q64 You have to use "ar -X64" and "strip -X64" on this platform also. Older 32-bit binaries run fine on this OS. sco_u3 -- SC0 3.2 and higher ______ - 12 - NOTE: If CRO is used, you will get lots of warnings during link. These are harmless and should be ignored. uname -a: SCO_SV sco 3.2 2 i386 cc: /bin/cc sgi32_u6 ________ uname -a: IRIX64 challenger 6.1 07121831 IP26 mips cc: /bin/cc -n32 -mips3 link: /bin/cc -n32 -mips3 Note that o32 format is in liblmgr_o32.a in this directory. sgi64_u6 ________ uname -a: IRIX64 challenger 6.1 07121831 IP26 mips cc: /bin/cc -n64 -mips3 link: /bin/cc -n64 -mips3 sun4_u5 _______ uname -a: SunOS backstage 5.1 Generic sun4m sparc cc: /opt/SUNWspro/bin/cc link: /bin/cc -lsocket -lnsl -lintl sun64_u5 _______ uname -a: SunOS ultra5 5.7 Generic_106541-02 sun4u sparc SUNW,Ultra-5_10 cc: /bin/cc -xarch=v9 link: /bin/cc -lsocket -lnsl -lintl -xarch=v9 -xildoff Older, 32-bit binaries run fine on this OS. Known bugs __________ P5422 Windows 2000 only: After license-finder popup, client can hang. This is a known bug in NTDLL on Windows 2000. It's planned to be fixed in a future Service Pack 2. It only occurs when o host is specified but no licenses are directly available to client. This can be done with @hostname or USE_SERVER license. - 13 - o The license server is not running on the host specified. Bugs fixed in v7.2e ___________________ Bug Severity Description ___________________________ P5552 1 Security problem affecting client and vendor daemon P5548 3 Solaris client fails when num fds > 1024 Bugs fixed in v7.2d ___________________ Bug Severity Description ___________________________ P5449 2 lc_feat_list can cause core dump P5467 2 NT ethernet address returns ffffffff. NT only. Works correctly on Win2000. Bugs fixed in v7.2c ___________________ Bug Severity Description ___________________________ P5331 3 server will not start if there are only uncounted increments P5379 2 flexlock fails with CRO P5393 2 flexlock fails with v7.1 and v7.2 P5423 1 Security problem in vendor daemon [Note: v7.2b was never released] Bugs fixed in v7.2a ___________________ Bug Severity Description ___________________________ P5304 2 .flexlmrc file can cause core dump. Bugs fixed in v7.1f ___________________ Bug Severity Description ___________________________ P5250 3 lc_hostid() function didn't return error status. P5252 4 lm_new.c has harmless array offset error P5259 2 reread can cause a core dump P5276 2 v7.0 client with SIGN= license can file w/ FUTURE/BADCODE err P5277 3 ether hostid on windows returns only 1 hostid - 14 - Bugs fixed in v7.1e ___________________ Bug Severity Description ___________________________ P5054 2 GENLIC can't make license without license-key P5122 4 Backslash in paths can disappear in messages (windows) P5138 3 Queueing can fail with checkout-filter P5155 4 Debuglog file not display vendor daemon port number P5159 1 DLL/Non-CRO/lc_new_job results in LM_BADCODE error P5186 4 C++ can't use lmprikey.h file for license-generator P5203 2 Package component checkin fails P5223 1 USE_SERVER/CRO can fail with LM_BADCODE Bugs fixed in v7.1d ___________________ Bug Severity Description ___________________________ P5192 3 lmgrd causes pre-v7.1 vendor daemons to be debug log in files named with a 8-char hex number that starts with 3. P5193 3 ether hostid fails on win2000 when disconnected from network. Bugs fixed in v7.1c ___________________ Bug Severity Description ___________________________ P5173 1 Default or zero values allowed in SEED3 and 4 P5129 1 Expiring vendorkeys exit with incorrect error. Bugs fixed in v7.1 ___________________ Bug Severity Description ___________________________ P3606 3 license-list/nodelocked in list can fail (vendor daemon) P4167 1 SUPERSEDE missing START/ISSUED can core dump(app) P4219 3 MAX, multiple checkouts in a job of same feature fails (vdaemon) P4257 2 SUPERSEDE/CHECKOUTFILTER/DUP_VENDOR problem (app) P4859 3 CHECKOUTFILTER, license-list can fail (app) P4897 4 makefile_md was buggy and is replaced P4930 3 lc_feat_list can get '' appended to feature name (app) P5002 3 LM_A_LF_LIST can omit <VENDOR>_LICENSE_FILE (app) P5007 3 REPORTLOG loses checkin with LINGER/reread (vdaemon) - 15 -